Clean dependencies #739
Clean dependencies #739
Conversation
|
Very important PR. We have |
| import JSON5 from 'json5'; | ||
| import { lilconfig } from 'lilconfig'; |
There was a problem hiding this comment.
what is the tradeoff for this. is lilconfig feature matched with cosmiconfig (given what we and users might depend on)?
There was a problem hiding this comment.
Feature match is the idea of lilconfig (but it has fewer dependencies and works faster). I moved from cosmiconfig to lilconfig in PostCSS Load Config and Size Limit without any problems.
| @@ -1,7 +1,7 @@ | |||
| import { NodePath } from '@babel/core'; | |||
| import generate from '@babel/generator'; | |||
| import * as t from '@babel/types'; | |||
| import get from 'lodash/get'; | |||
| import get from 'lodash.get'; | |||
There was a problem hiding this comment.
I really dislike these little packages. they may be smaller but it usually balloons the dep tree and number of transitive dependencies significantly. What is the actual cost saves between all of them over installing lodash. TBH I don't understand this sort of optimization, even on slow networks installing 70kb of text is not expensive, in the context of "putting files on disk to do development", I would imagine (unscientifically) having more limited deps, thereby reducing the amount of network hops and logic required by bundlers to install would be faster overall.
There was a problem hiding this comment.
lodash is 1.3 MB vs 23 KB for lodash.get
For instance, I don't have lodash in subdependecies of my projects. Adding extra MB will slow down CI by a few seconds.
There was a problem hiding this comment.
@RKatarine @jquense @ai can we replace lodash by native ECMAScript features?
This PR has been motivated by the issue
comsiconfigtolilconfig;lodashwith speciallodash.xwith a specific function;@types/fs-extraglobbytofast-glob